Collection of Tools & Utilities/Collection of Tools and Utilities.iso/asmutil/d86v322.zip/D03.DOC

Text File | 1990-01-25 | 16KB | 378 lines

CHAPTER 3   REQUIREMENTS AND OPERATION


System Requirements for D86

D86 currently requires either an IBM-PC or compatible computer, a
Texas Instruments TI-PC, a Wang PC, a Tandy 2000, a DEC Rainbow,
or a Sanyo 550 or 555 computer. The computer must be running
MS-DOS V2.00 or later.  The IBM compatibility must exist at the
BIOS and video interface levels: D86 calls the BIOS to obtain
keystrokes and video status information; and, on an IBM-PC, D86
writes directly to video memory at segment 0B000 (if the BIOS
says monochrome) or 0B800 (if color).

I will be happy to work with you to add support for your
non-IBM-PC compatible MS-DOS computer.  See the end of this
chapter for the first steps in helping me do so.

D86 is fairly flexible about memory management.  If there is
enough memory, D86 will take the combined sizes of D86.COM and
A86.COM (currently about 38K bytes), plus 64K bytes for its own
stack, and leave the rest for the program being debugged.  If
memory is tight, D86 will reduce the memory allocated to its own
stack, down to a minimum of 16K bytes.  The segment occupied by
the program being debugged will be similarly reduced.  If the
program is a COM file, you can tell this by the initial SP value,
which is 0FFFE if there is a full 64K, less if there isn't.
Thus, D86 will work with as little as 70K bytes beyond the
operating system; but the symbols capacity and the program's
memory will be severely limited in that case.  It is best to have
at least 166K bytes of memory available when D86 is running.


Invoking D86

You invoke D86 by issuing the command

   D86 [+V] [progname [command-tail]]

where progname is the name of the program you are debugging.  In
other words, you type a program invocation line just as if you
were about to execute the program without a debugger, except that
you append D86 before the line.

The following sections describe in detail the elements of the D86
invocation line, and how D86 acts on them.



Finding the Program File

On most other debuggers, you have to give the full file name,
with an explicit extension and a specific directory.  With D86,
you don't: D86 uses almost the same algorithm for locating a
program file that COMMAND.COM does:

1. Look for COM, then EXE, then BAT in the current directory.
                                                              3-2

2. Look for COM, then EXE, then BAT in each directory in turn
   given in the PATH environment variable.

The one difference is that D86 will look only for one extension
if you give an explicit extension (and it doesn't have to be COM,
EXE, or BAT).  COMMAND.COM ignores the extension you give-- I
thought that was just too absurd, and didn't duplicate it.

A strange feature that I did duplicate is COMMAND.COM's lack of
concern for whether the program is named COM or EXE.  If the
program file begins with a valid EXE header, it's treated as an
EXE no matter what it is named.  If not, then it's treated as a
COM file.

D86 provides limited support for BAT files.  (That's better than
other debuggers, which provide no support.)  If your program is a
BAT file, D86 reads the first line of the file and pretends that
that was what you typed following "D86" in your invocation.  The
D86 status screen (gotten via Ctrl-S) gives you this line, and
tells you what BAT file it came from.

The BAT file limitations are that D86 doesn't skip over remark
lines, doesn't substitute batch-file parameters, and doesn't
perform console redirection specified in the batch-file line.

You can also invoke D86 with no progname.  The debugger comes up
with no program loaded, allowing you to simply poke around the
machine.

If D86 had a problem loading your program, you'll see all NOPs in
memory instead of instructions.  You can type Ctrl-S to get the
status screen that tells you what the problem was.



Finding the Symbols File

D86 is a symbolic debugger.  It uses a special .SYM file produced
in one of three ways:  First, if your program was produced by
A86, then the .SYM file was produced by A86 at the same time.
Second, if your program was produced by a high-level language
such as Pascal or C, you can feed the linker's .MAP listing to
the special MAPD86 tool, available to registered D86 users only.
Third, you can "reverse engineer" a program by adding symbols
while in D86's patch mode, then create a .SYM file with D86's W
command.
                                                              3-3

When invoked, D86 looks for a file with the program's name and a
.SYM extension.  D86 first looks in the current directory for
this file, and then in each directory specified in the PATH
environment variable.  It is not necessary for the SYM file to
exist.  If there is no SYM file, the debugger simply comes up
with no user symbols defined.  You'll also get no user symbols if
the SYM file was not of a correct format (it wasn't produced in
one of the ways mentioned in the previous paragraph, or it has
been corrupted in some way).  If you were expecting symbols and
didn't get any, you can press Ctrl-S to get the status screen
that tells you what the problem was.


Two-Screen Debugging with +V

The +V option can be used if you have both a monochrome and a
color monitor.  You invoke D86 when the operating system is on
one monitor-- with the +V switch, the debugger will appear on the
other monitor, and program console output will appear on the
operating system's monitor.

In order for the +V option to work, you must initialize both
screens by MODEing to them sometime after powering up the
machine. You should also make sure that the blinking cursor is at
the bottom of the screen on which the debugger will appear (the
simplest way to do this is to type ENTER until the prompt gets to
the bottom).  If you can suppress the blinking cursor, that's
even better.  See in your DOS operating manual for instructions
on how to use MODE to switch between screens.  D86 doesn't do the
initialization, because I couldn't figure out how to get the BIOS
to do so without blanking the screen, and you might not want the
screen blanked every time you start a D86 session.



The D86 Screen Display

When D86 starts up, it generates a full-screen display, and
awaits your debugger commands.

In the top part of the screen is a symbolic disassembly of the
A86 program, with the screen cursor positioned next to the
instruction pointed to by the 8086 instruction pointer.

In the lower left corner is a fixed display of the complete 8086
register set.

At the top of the second column of the register-set display is a
display of the 8086 flags.  Each flag displays as blank if the
flag is off; a lower case letter if the flag is on:
                                                              3-4

     o   for overflow,
     d   for direction,
     i   for interrupts enabled,
     s   for sign,
     z   for zero,
     a   for auxiliary carry,
     e   for parity even, and
     c   for carry.

Across the bottom line of the screen is a display of the contents
of the user stack.  The display begins next to the SP register
value, with the number of elements on the stack.  (The stack is
assumed to have 0 elements when SP is at its original value,
which is 0FFFE for COM files, and a value specified in the header
record for EXE files). The number of elements is followed by a
colon, followed by as many of the top stack elements as fits on
the line.  The initial display will have zero elements; nothing
is yet on the stack.

To the right of the registers are 6 lines, numbered 1 through 6.
On these lines, you can generate windows into 8086 memory,
displaying bytes, words, or ASCII text in a variety of formats.
The windows can be located either at absolute memory locations,
or be pointed to by any of the 8086 registers.  The commands you
issue to generate these windows are described in Chapter 6.


D86 Commands

There are 5 kinds of activities you perform in D86:

   1. Issuing assembly language commands for immediate execution

   2. Issu